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Abstract — With  on-demand  routing,  a  router  maintains  routing  information  for 
only  those  destinations  that  need  to  be  reached  by  the  router.  The  approaches  used  to 
date  to  eliminate  long-term  or  permanent  loops  in  on-demand  routing  consist  of  ob¬ 
taining  complete  routes  to  destinations  dynamically,  or  obtaining  only  the  next  hops 
to  destinations  and  validating  the  information  using  sequence  numbers  or  internodal 
synchronization.  We  present  a  new  approach  to  on-demand  routing,  which  we  call 
the  DST  (dynamic  source  tree)  protocol.  To  eliminate  looping,  routers  in  DST  com¬ 
municate  paths  to  destinations;  however,  only  incremental  updates  to  such  paths  are 
communicated  by  specifying  the  second-to-last  hop  and  distance  to  each  node  in  the 
subpath  to  the  destination  that  must  be  updated.  Simulations  experiments  are  used 
to  show  that,  in  terms  of  control  packet  overhead,  DST  outperforms  substantially  the 
Dynamic  Source  Routing  (DSR)  protocol  which  is  arguably  one  of  the  most  efficient 
on-demand  routing  approaches  to  date,  while  achieving  similar  performance  in  terms 
of  the  average  delay  and  throughput  of  data  packets. 

I.  Introduction 

On-demand  routing  protocols  have  been  designed  to  limit  the  amount 
of  bandwidth  consumed  in  maintaining  up-to-date  routes  to  all  destina¬ 
tions  in  a  network  by  maintaining  routes  to  only  those  destinations  to 
which  the  routers  need  to  forward  data  traffic.  The  basic  approach  con¬ 
sists  of  allowing  a  router  that  does  not  know  how  to  reach  a  destination 
to  send  a  flood-search  message  to  obtain  the  path  information  it  needs. 
There  are  several  recent  examples  of  this  approach  (e.g.,  AODV  [11], 
ABR  [12],  DSR  [8],  TORA  [10],  SSA  [3],  ZRP  [7])  and  the  routing 
protocols  differ  on  the  specific  mechanisms  used  to  disseminate  flood- 
search  packets  and  their  responses,  cache  the  information  heard  from 
other  nodes'  searches,  determine  the  cost  of  a  link,  and  determine  the 
existence  of  a  neighbor.  However,  all  the  on-demand  routing  propos¬ 
als  use  flood  search  messages  that  either:  (a)  give  sources  the  entire 
paths  to  destinations,  which  are  then  used  in  source-routed  data  packets 
(e.g.,  DSR);  or  (b)  provide  only  the  distances  and  next  hops  to  desti¬ 
nations,  validating  them  with  sequence  numbers  (e.g.,  AODV)  or  time 
stamps  (e.g.,  TORA).  One  problem  with  source  routing  is  that  it  results 
in  long  data-packet  headers  as  the  network  size  increases.  On  the  other 
hand,  protocols  that  use  sequence  numbers  or  timestamps  incur  addi¬ 
tional  overhead  in  resetting  the  sequence  number  and  timestamps  in  the 
presence  of  partitions  and  node  failures. 

In  this  paper,  we  introduce  and  analyze  the  DST  (dynamic  source 
tree)  protocol,  which  constitutes  a  new  approach  for  on-demand  dis¬ 
tance  vector  routing  in  ad  hoc  networks.  As  in  other  on-demand  rout¬ 
ing  algorithms,  DST  acquires  routes  to  destinations  only  when  traffic 
for  those  destinations  exists  and  there  is  no  correct  route  to  the  des¬ 
tination.  The  acquired  route  does  not  have  to  be  the  shortest  path;  it 
has  to  be  valid  and  of  finite  metric  value.  DST  does  not  use  source- 
routed  packets  or  time  stamps  to  validate  distance  updates.  DST  uses 
a  source-tracing  algorithm  similar  to  the  one  advocated  in  prior  table- 
driven  routing  protocols  in  which  routers  maintain  routing  information 
for  all  network  destinations  [9],  Using  information  about  the  length 
and  second-to-last  hop  ( predecessor )  of  the  shortest  path  to  all  known 
destinations,  the  source  tracing  algorithm  reduces  the  number  of  loops 
and  removes  the  counting  to  infinity  problem  of  the  distributed  Bellman 
Ford  algorithm. 

This  work  was  supported  in  part  by  the  Defense  Advanced  Research  Projects  Agency  (DARPA)  under 
grant  F30602-97-2-0338. 


There  are  three  key  contributions  of  this  paper:  (i)  introducing  a  new 
approach  that  uses  a  source-tracing  algorithm  for  on-demand  routing, 
(ii)  presenting  the  design  of  a  protocol  that  does  not  use  sequence  num¬ 
bers  or  internodal  synchronization  to  ensure  correctness  and  (iii)  show¬ 
ing  through  simulations  that  DST  incurs  less  control  overhead  than 
DSR  in  most  situations. 

Section  II  gives  a  detailed  description  of  DST  and  presents  examples 
illustrating  the  working  of  the  protocol.  Section  III  uses  simulations  to 
compare  DST’s  performance  with  the  performance  of  DSR  using  the 
same  simulation  code  and  model  used  in  [1]  to  compare  DSR  against 
other  on-demand  routing  protocols. 

II.  The  DST  Protocol 

A.  Network  Model 

To  describe  DST,  a  network  is  modelled  as  an  undirected  graph  with 
V  nodes  and  E  links.  A  router  has  a  single  node  identifier,  and  a  node 
has  radio  connectivity  with  multiple  nodes  through  a  single  physical 
radio  link.  We  map  a  physical  broadcast  link  connecting  a  node  and 
its  multiple  neighbors  into  point-to-point  links  between  the  node  and 
its  neighbors.  Each  link  has  a  positive  cost  associated  with  it.  If  a  link 
fails,  its  cost  is  set  to  infinity.  A  node  failure  is  modelled  as  all  links 
incident  on  the  node  getting  set  to  infinity. 

For  the  purpose  of  routing-table  updating,  a  node  A  considers  an¬ 
other  node  B  as  its  neighbor  if  A  receives  an  update  from  neighbor  B. 
Node  B  is  no  longer  node  A"s  neighbor  when  the  medium  access  pro¬ 
tocol  at  node  A  sends  a  signal  to  DST  indicating  that  data  packets  can 
no  longer  be  sent  successfully  to  node  B. 

Routing  messages  are  broadcast  unreliably  and  the  protocol  assumes 
that  routing  packets  may  be  lost  due  to  changes  in  link  connectivity,  fad¬ 
ing  or  jamming.  Since  DST  only  requires  a  MAC  indication  that  data 
packets  can  no  longer  be  sent  to  a  neighbor,  the  need  for  a  link-layer 
protocol  for  monitoring  link  connectivity  with  neighbors  or  transmit¬ 
ting  reliable  updates  is  eliminated,  thus  reducing  control  overhead.  If 
such  a  layer  can  be  provided  with  no  extra  MAC  overhead,  then  DST 
can  be  made  more  proactive  by  identifying  lost  neighbors  before  data 
for  them  arrives,  resulting  in  faster  convergence  and  decreased  data 
packets  losses. 

B.  Routing  Information  maintained  in  DST 

A  router  in  DST  maintains  a  routing  table,  a  distance  table,  a  data 
buffer  and  a  query  table. 

The  routing  table  at  router  i  contains  entries  for  destinations  needed 
by  the  router.  Each  entry  consists  of  the  destination  identifier  j,  the  suc¬ 
cessor  to  that  destination  sj,  the  second-to-last-hop  to  the  destination 
Pj,  the  distance  to  the  destination  Dj  and  a  route  tag  tagf  When  the 
element  tag ij  is  set  to  correct,  it  implies  a  loop-free  finite  value  route. 
When  it  is  set  to  null,  it  implies  that  the  route  still  has  to  be  checked 
and  when  it  is  set  to  error,  an  infinite  metric  route  or  a  route  with  a 
loop  is  implied. 

The  distance  table  at  router  j  is  a  matrix  containing,  for  each  k  6  Ni 
(where  Ni  is  the  list  of  known  neighbors)  and  each  destination  j  needed 
by  such  neighbor,  the  distance  value  of  the  route  from  i  to  j  through  k, 
Djk  and  the  second-to-last  hop  plk  on  that  route.  Djk  is  always  set 
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equal  to  RDj  +  lk,  where  RDj  is  the  distance  reported  by  k  to  j  in 
the  last  routing  message  and  Pk  is  the  link  cost  of  link  (i.  k). 

The  data  buffer  is  a  queue  that  holds  all  the  data  packets  waiting  for 
routes  to  destinations.  There  are  various  schemes  to  do  buffer  manage¬ 
ment  but  we  chose  to  use  the  scheme  used  by  most  existing  on-demand 
routing  protocols.  Each  data  packet  also  has  a  time  value,  which  is  set 
to  the  time  when  the  packet  is  put  into  the  buffer.  A  packet  that  has  been 
in  the  buffer  for  more  than  data. pkt  .timeout  seconds  is  dropped.  The 
data  buffer  is  checked  periodically  for  any  packets  that  may  be  sent  or 
dropped. 

The  query  table  is  used  to  prevent  queries  from  being  forwarded  in¬ 
definitely.  As  in  DSR,  there  are  two  types  of  queries;  queries  with 
zero  hop  count  which  just  get  propagated  to  neighbors  and  queries 
with  maximum  hop  count  that  are  forwarded  to  a  maximum  distance 
of  MAX-HOPS  hops  from  the  sender.  For  a  destination  j,  the  query 
table  contains  the  last  time  a  maximum  hop  query  was  sent  qs*-,  the 
last  time  a  zero  hop  query  was  sent  zqSj,  the  hop  count  of  the  last 
query  sent  hqs'j ,  the  last  time  a  query  was  received  qr ] .  At  the  source 
of  the  flood  search,  two  maximum  hop  count  queries  are  always  sep¬ 
arated  by  query s end-timeout  seconds.  A  query  is  forwarded  by  a 
receiver  only  if  the  difference  between  the  time  it  is  received  and  qr j  is 
greater  than  query  -receive  -timeout,  where  query  .receive -timeout 
is  slightly  lesser  than  query  -send. timeout. 

C.  Routing  Information  exchanged  in  DST 

There  are  two  types  of  control  packets  in  DST  -  queries  and 
updates.  All  control  packets  headers  have  the  source  of  the  packet 
( pkt.src ),  the  destination  of  the  packet  (pkt.dst),  the  number  of  hops 
( pkt.hops )  and  an  identifier  pkt.type  that  can  be  set  to  QUERY  or 
UPDATE.  Each  packet  has  a  list  of  routing  entries,  where  each  en¬ 
try  specifies  a  destination  j,  a  distance  to  the  destination  RDj  and  a 
predecessor  to  the  destination  rpj . 

If  the  MAC  layer  allowed  for  transmission  of  reliable  updates  with 
no  retransmission  overhead,  only  incremental  routing  updates  could  be 
sent.  In  this  paper,  however,  we  assume  a  MAC  protocol  based  on 
collision  avoidance,  in  which  sending  larger  control  packets  does  not 
decrease  throughput  at  the  MAC  layer,  because  the  overhead  for  the 
MAC  protocol  to  acquire  the  channel  does  not  depend  on  packet  size 
[5],  [6].  Therefore,  in  the  rest  of  the  paper,  we  assume  that  routers 
transmit  their  entire  routing  tables  when  they  send  control  messages. 
Control  packet  size  may  affect  the  delay  experienced  by  packets  in  the 
MAC  layer.  However,  as  our  simulations  show,  this  does  not  affect 
data  packet  delays  because  the  number  of  control  packets  we  generate 
is  substantially  low. 

Data  packets  in  DST  only  need  to  have  the  source  and  destination  in 
the  header,  rather  than  the  source  routes  as  in  DSR. 

D.  Creating  Routes 

When  a  network  is  brought  up,  each  node  (i)  adds  a  route  to  itself 
into  its  routing  table  with  a  distance  metric  (D\ )  of  zero,  the  successor 
set  equal  to  itself  (i)  and  the  tag  ( tag \)  set  to  correct.  To  differentiate 
a  route  to  itself  from  all  other  routes,  a  node  sets  the  local  host  address 
(127.0.0.1)  as  the  predecessor  to  itself. 

When  a  data  packet  is  sent  by  an  upper  layer  to  the  forwarding  layer, 
the  forwarding  layer  checks  to  see  if  it  has  a  correct  path  to  the  desti¬ 
nation.  If  it  does  not,  then  the  packet  is  queued  in  the  buffer  and  the 
router  starts  a  route  discovery  by  broadcasting  queries.  Route  discov¬ 
ery  cycles  are  separated  by  query  .receive -timeout  seconds.  One  zero 
hop  query  and  one  maximum  hop  query  are  sent  in  every  cycle.  A 
zero  hop  query  allows  the  sender  to  query  neighboring  routing  tables 
with  one  broadcast.  If  the  zero  hop  query  times  out  ((present  time  - 
zqs'j)  >  zero.qry. send. timeout ),  then  an  unlimited  hop  query  (with 
pkt.hops  set  to  MAX-HOPS)  is  sent  out.  Consider  the  six-node  net¬ 
work  in  Fig.  l.a  where  all  link  costs  are  of  unit  value  and  where  node  d 


broadcasts  a  query  for  destination  a  ,  with  the  pkt.src  set  to  d,  pkt.dst 
set  to  a,  and  pkt.hops  set  to  MAX-HOPS.  The  parenthesis  next  to 
each  node  in  the  example  depicts  the  routing  table  entry  (distance,  pre¬ 
decessor)  for  destination  a.  The  symbol  Ih  stands  for  local  host  address 
(127.0.01).  The  query  packet  contains  a  list  of  all  the  routing  table  en¬ 
tries  of  the  sender  d.  The  entries  are  shown  within  the  square  brackets, 
each  entry  in  the  (destination,  distance,  predecessor)  form.  The  entries 
are  in  a  increasing  distance  order,  such  that  a  node  i  receiving  a  query 
from  an  unknown  neighbor  k,  adds  the  neighbor  k  to  its  distance  tables 
on  reading  the  first  entry  in  the  query  and  proceeds  to  consider  all  other 
entries  as  the  distances  reported  by  k. 

Consider  the  node  e,  where  a  query  is  received.  To  process  the 
query,  each  entry  (j,  RDj  ,rpj)  is  read.  If  the  entry  is  for  an  un¬ 
known  destination,  then  the  destination  is  initialized  (D'j  -*  oo, 
Pj ,  Sj  -¥  NULL.ADDR ;  D)k  ->  oo,  p)k  -A  NULL.ADDR 
Mk  €  Ni.  Then,  the  distance  table  entry  for  neighbor  d  is  updated. 
Since  the  distance  RD\ j  is  equal  to  zero,  d  is  marked  as  a  neighbor. 
The  value  for  j  reported  by  other  neighbors  whose  path  contains  d  is 
also  updated.  This  step  helps  prevent  permanent  loops  by  preemptively 
removing  stale  information. 

Finally,  routing  table  entries  are  updated  to  pick  as  successor  a  neigh¬ 
bor  k  to  destination  j  if  both  the  following  conditions  are  true 

1.  k  offers  the  shortest  distance  to  all  nodes  in  the  path  from  j  to  i. 

2.  the  path  from  j  to  k  does  not  contain  i  and  does  not  contain  any 
repeated  nodes. 

If  either  of  the  two  conditions  are  not  satisfied,  then  taglj  is  set  to  error. 
Else,  it  is  set  to  correct  and  neighbor  k  is  designated  the  successor  and 
the  distance  value  to  j  is  set  to  D'-k  and  the  predecessor  is  set  to  pljk. 

After  processing  all  entries  and  updating  the  routing  table,  the  node  e 
checks  to  see  if  it  has  a  route  to  a.  Since  there  is  no  route,  a  query  packet 
is  broadcasted  with  the  same  header  fields  as  the  processed  query,  be¬ 
sides  pkt.hops  which  is  decremented  by  one  if  (a.)  a  node  does  not 
have  a  route  to  pkt.dst ,  (b.)  pkt.hops  is  greater  than  one,  and  (c.) 
if  the  time  elapsed  since  the  last  query  was  received  is  greater  than 
query. receive. timeout 

The  routing  entries  added  to  the  forwarded  query  reflect  the  rout¬ 
ing  table  entries  of  current  node  e.  The  packet  is  then  broadcasted  to 
the  limited  broadcast  address.  In  Fig.  l.b,  nodes  e,  /  and  c  broadcast 
queries. 

In  Fig.  l.c,  we  see  that  nodes  e,  /,  a  do  not  send  any  more 
queries  because  the  time  elapsed  since  the  last  query  sent  is  lesser  than 
query  .receive -timeout.  On  the  other  hand,  at  nodes  a  and  6,  a  finite 
and  valid  route  to  a  is  found  and  a  reply  update  is  sent.  A  reply  update 
sent  by  a  node  i  has  a  different  structure  than  a  regular  update,  which 
has  pkt.dst  set  to  the  limited  broadcast  address  and  pkt.src  set  to  i. 
The  reply  update  sent  by  b  has  field  pkt.dst  set  to  the  pkt.src  —  d  of 
the  query  and  the  field  pkt.src  set  to  the  pkt.dst  —  a  of  the  query.  All 
updates  are  broadcast  to  the  limited  broadcast  address. 

When  node  i  receives  an  update,  it  checks  the  value  of  pkt.dst.  If  it 
is  set  to  a  value  other  than  the  limited  broadcast  address,  then  the  up¬ 
date  being  sent  is  a  reply  update,  else  it  is  a  regular  update.  The  entries 
are  processed  in  a  manner  similar  to  the  entries  of  the  query.  A  regular 
update  is  broadcast  in  response  to  a  regular  update,  with  pkt.dst  set  to 
the  limited  broadcast  address  and  pkt.src  set  to  i  if  (a.)  the  distance 
to  a  known  destination  increases,  or  (b.)  if  a  node  loses  the  last  finite 
route  to  a  destination.  The  reply  update  has  different  rules  for  propaga¬ 
tion.  In  Fig  l.d  ,  a  reply  update  is  rebroadcasted  by  e  with  the  original 
pkt.dst  and  pkt.src,  because  (a.)  a  finite  path  to  pkt.dst  —  d  exists, 
and  (b.)  the  distance  to  pkt.src  —  a  changes  from  infinite  to  finite  after 
processing  the  reply  update.  Nodes  a  and  b  do  not  rebroadcast  reply  up¬ 
dates  because  the  second  condition  is  not  satisfied.  Node  d  gets  a  reply 
update  from  node  e  and  will  set  its  successor  to  node  e  after  processing 
the  entries  in  the  query.  Node  d  does  not  send  any  more  reply  updates. 
However,  a  regular  update  will  be  sent  if  any  of  the  two  conditions  for 


TABLE  II 

Constants  used  in  DST  simulation 


Query  send  timeout 

5  sec 

Zero  query  send  timeout 

30  msec 

Data  packet  timeout 

30  sec 

Max  number  of  pending  packets 

50 

Query  receive  timeout 

4.5  sec 

MAXJTOPS 

17 

A.  Scenarios  used  in  comparison 

We  compared  DSR  and  DST  using  two  types  of  scenarios.  In  both 
scenarios,  we  used  the  “random  waypoint”  model  described  in  [1].  In 
this  model,  each  node  begins  the  simulation  by  remaining  stationary  for 
pause  time  seconds  and  then  selects  a  random  destination  and  moves  to 
that  destination  at  a  speed  of  20  m/s.  Upon  reaching  the  destination,  the 
node  pauses  again  for  pause  time  seconds,  selects  another  destination, 
and  proceeds  there  as  previously  described,  repeating  this  behavior  for 
the  duration  of  the  simulation.  We  used  the  speed  of  20m/s,  which 
is  the  speed  of  a  vehicle,  because  it  has  been  used  in  simulations  in 
earlier  papers  [1],  [2]  and  thus  provides  a  basis  for  comparison  with 
other  protocols.  In  both  scenarios,  we  used  a  50  node  ad-hoc  network, 
moving  over  a  flat  space  of  dimensions  7X6  miles  (11.2  X  9.7  km) 
and  initially  randomly  distributed  with  a  density  of  approximately  one 
node  per  square  mile. 

Two  nodes  can  hear  each  other  if  the  attenuation  value  of  the  link 
between  them  is  such  that  packets  can  be  exchanged  with  a  probabil¬ 
ity  p,  where  p  >  0.  Attenuation  values  are  recalculated  every  time  a 
node  moves.  Using  our  attenuation  calculations,  radios  have  a  range  of 
approximately  4  miles  (135  db). 

We  have  random  data  flows,  where  each  flow  is  a  peer-to-peer  con¬ 
stant  bit  rate  (CBR)  flow  and  the  data  packet  size  is  kept  constant  at  64 
bytes.  Data  flows  were  started  at  times  uniformly  distributed  between 
20  and  120  seconds  and  they  go  on  till  the  end  of  the  simulation.  The 
total  load  on  the  network  is  kept  constant  at  80  data  packets  per  second 
(40.96  kbps)  to  reduce  congestion.  Our  rationale  for  doing  this  is  that 
increasing  the  packet  rate  of  each  data  flow  does  not  test  the  routing 
protocol.  On  the  other  hand,  having  flows  with  varying  destinations 
does  so.  We  also  vary  the  pause  times:  0,  30,  60,  120,  300,  600  and  900 
seconds  as  done  in  [1], 

In  the  first  scenario,  there  are  20  CBR  sources,  each  of  which  estab¬ 
lishes  a  connection  with  a  randomly  picked  destination. 

In  the  second  scenario,  the  number  of  sources  is  fixed  at  10  sources 
with  60  flows  and  each  source  has  peer-to-peer  connections  with  6 
destinations.  This  scenario  helps  us  evaluate  the  scalability  of  the  ap¬ 
proaches  with  respect  to  the  number  of  outward  flows  each  source  has. 

B.  Metrics  used 

In  comparing  the  two  protocols,  we  use  the  following  metrics: 

•  Packet  delivery  ratio :  The  ratio  between  the  number  of  packets  re¬ 
ceived  by  an  application  and  the  number  of  packets  sent  out  by  the 
corresponding  peer  application  at  the  sender. 

•  Control  Packet  Overhead'.  The  total  number  of  routing  packets  sent 
out  during  the  simulation.  Each  broadcast  packet  is  counted  as  a  single 
packet. 

•  End  to  End  Delay :  The  delay  a  packet  suffers  from  leaving  the  sender 
application  to  arriving  at  the  receiver  application.  Since  dropped  pack¬ 
ets  are  not  considered,  this  metric  should  be  taken  in  context  with  the 
metric  of  packet  delivery  ratio. 

Packet  delivery  ratio  gives  us  an  idea  about  the  effect  of  routing  policy 
on  the  throughput  that  a  network  can  support.  It  also  is  a  reflection  of 
the  correctness  of  a  protocol. 


Control  packet  overhead  has  an  effect  on  the  congestion  seen  in  the 
network  and  also  helps  evaluate  the  efficiency  of  a  protocol.  Low  con¬ 
trol  packet  overhead  is  desirable  in  low-bandwidth  environments  and 
environments  where  battery  power  is  an  issue. 

Average  end-to-end  delay  is  not  an  adequate  reflection  of  the  delays 
suffered  by  data  packets.  A  few  data  packets  with  high  delays  may 
skew  results.  Therefore,  we  plot  the  cumulative  distribution  function 
of  the  delays.  This  plot  gives  us  a  clear  understanding  of  the  delays 
suffered  by  the  bulk  of  the  data  packets.  Delay  also  has  an  effect  on  the 
throughput  seen  by  reliable  transport  protocols  like  TCP. 

C.  Simulation  results 
C.l  Scenario  1 

Scenario  1  is  identical  to  the  one  presented  in  [1],  There  are  20  CBR 
sources  each  of  which  picks  a  random  destination  to  send  traffic  to. 

Fig.  2  shows  the  control  packet  overhead  for  varying  pause  times.  An 
obvious  result  is  that  the  control  packet  overhead  for  both  the  protocols 
reduces  as  the  pause  time  increases.  DST  is  about  34  %  better  than  DSR 
at  pause  time  zero.  At  low  rates  of  movement,  DST  is  a  clear  winner 
with  one  tenth  the  control  packet  overhead  of  DSR.  Clearly,  the  fact  that 
the  updates  in  DST  contain  the  entire  routing  table,  means  that  nodes 
running  DST  have  a  higher  chance  of  knowing  paths  to  destinations  for 
whom  no  route  discovery  has  been  performed  in  the  past.  We  are  able 
to  mimic  the  behavior  of  table-driven  routing  protocols  in  low  topology 
change  scenarios,  in  that  we  almost  have  information  about  the  entire 
topology  with  very  few  flood  searches. 

As  shown  in  Fig.  3,  at  lower  pause  times,  DSR  has  the  same  packet 
delivery  ratio  as  DST.  However,  as  the  pause  time  decreases,  DSR  suf¬ 
fers  due  to  data  packets  getting  dropped  at  the  link  layer,  indicating 
that  the  routes  provided  in  the  source  routes  are  not  correct  any  more. 
At  lower  pause  times,  links  get  broken  faster.  Even  though  this  results 
in  higher  control  overhead,  the  routes  obtained  are  relatively  new.  As 
mentioned  earlier,  we  keep  the  load  on  the  network  constant.  Since  this 
load  is  divided  among  a  large  number  of  flows,  we  see  veiy  little  con¬ 
gestion  and  therefore  most  packets  get  through  at  higher  pause  times 
during  which  the  topology  is  close  to  static. 

Fig.  4  shows  the  cumulative  delay  of  the  protocols.  The  graphs 
shown  are  logarithmic  in  time  to  accommodate  the  wide  variation.  Al¬ 
most  all  packets  are  sent  within  8  seconds  in  DST  while  some  packets 
in  DSR  take  almost  30  seconds.  This  is  because  a  packet  is  allowed 
to  stay  in  a  buffer  for  a  maximum  of  30  seconds  before  it  is  dropped. 
These  are  packets  that  found  the  path  just  in  time. 

C.2  Scenario  2 

Fig.  5  show  the  amount  of  control  packet  overhead  each  protocol 
incurs  for  varying  pause  times.  In  both  protocols  control  packet  over¬ 
head  is  a  function  of  the  workload  and  the  changes  in  link  connectivity. 
The  control  overhead  of  DSR  is  substantially  higher  than  DST.  almost 
580%  higher.  Due  to  the  nature  of  on-demand  routing  protocols,  both 
protocols  show  higher  overhead  when  there  are  flows  to  more  destina¬ 
tions. 

Fig.  6  shows  the  percentage  of  data  packets  received.  This  metric 
shows  very  similar  behavior  for  both  DSR  and  DST,  rising  rapidly  af¬ 
ter  pause  time  15.  Since  there  is  very  little  congestion  due  to  control 
packets  at  the  higher  pause  time,  most  of  the  data  packets  get  through. 

Fig.  7,  show  the  delay  behavior  of  the  data  packets  and  DSR  per¬ 
forms  marginally  better. 

IV.  Conclusions 

We  presented  DST,  which  is  an  on-demand  routing  algorithm  based 
on  a  source  tracing  algorithm.  DST  does  not  use  sequence  numbers  and 
therefore  is  not  prone  to  inefficiencies  in  the  presence  of  node  failures; 
this  leads  us  to  suggest  that  our  scheme  of  using  only  local  timestamps 
to  prevent  indefinite  route  queries  can  be  adopted  by  other  one-demand 
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Fig.  6.  Percentage  of  data  packets  received  for  60  flows  -  10  sources,  6  destinations 


Fig.  2.  Number  of  control  packets  sent  for  20  sources  picking  random  destinations  for 
peer-to-peer  flow 
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Fig.  3.  Percentage  of  data  packets  received  for  20  sources  picking  random  destinations  for 
peer-to-peer  flow 
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Fig.  4.  Cumulative  delay  for  pause  time  0,  20  sources  picking  random  destinations  for 
peer-to-peer  flow 
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Fig.  5.  Number  of  control  packets  sent  for  60  flows  -  10  sources,  6  destinations 
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Fig.  7.  Cumulative  delay  sent  for  60  flows  -  10  sources,  6  destinations  {pause  time  0) 

routing  protocols  to  prevent  routing  inefficiencies.  DST  also  does  not 
use  reliable  updates  or  polling  of  neighbors.  This  implies  that  DST  cre¬ 
ates  substantially  less  overhead  than  protocols  that  use  the  above  fea¬ 
tures.  We  introduce  conditions  that  reduce  control  packet  overhead  at 
the  expense  of  non-optimal  routes,  all  the  while  preventing  permanent 
looping  of  data  packets. 

Simulations  were  used  to  compare  our  protocol  against  DSR,  which 
is  arguably  one  of  the  most  efficient  on-demand  routing  protocols  re¬ 
ported  in  literature.  For  all  scenarios.  DST  performs  consistently  better 
than  DST  with  respect  to  control  overhead.  The  results  for  delay,  hop 
count  and  percentage  of  data  packets  received  are  mixed,  which  leads 
us  to  believe  that  both  protocols  are  at  par  when  performance  in  these 
metrics  is  taken  into  consideration.  Our  simulations  results  show  that 
DST  is  very  suitable  for  ad-hoc  networks  and  incurs  limited  control 
overhead,  even  in  cases  of  high  mobility. 
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